July 4, 1987 GFATIP06.DOC by John B. Holder Senior Software Engineer Marathon Computer Press Asst. Sysop on GEnie's MichTron Roundtable This is the 6th in a planned series of GFA Tip files. The topic of this issue is "Multi-Tasking with GFA Basic, To Be or Not to Be". Before we get into the nitty gritty of the subject, a bit of background is necessary first. If you are an experienced programmer with a background in Multi-Tasking operating systems such as UNIX then please excuse the intro to the subject. Multi-Tasking Myths-vs-Reality Myth: When Multi-tasking on a one CPU system, you actually run several concurrent processes all at the same time. Reality: A single CPU system that Multi-Tasks actually allows several jobs to be started and be scheduled concurrently, however the CPU's time is actually shared among the processes. This is where you might have heard the term "Time-Sharing System". The operating system creates several shells for ongoing processes, and switches among the active scheduled processes in such a manner as to give the impression of simultaneous execution. There are several excellent software packages that use this scheme of process "sharing" on the ST. Most notably are David Beckemeyer's MT C Shell, Flight Simulator, and Silent Service to name a few. So the big question at this point is, "Why Not GFA Basic Too?" Well, the answer is "It is possible if several factors are taken into consideration and worked out properly." So, now let's get on with the background of a Multi-Tasking Operating System or Application. At the heart of any Multi-Tasking application is what is known as a Kernel. The Kernel must control access to the computer, manage memory assets, maintain the file system, and allocate available resources to the calling procedures or users. It is analogous to a traffic cop. This is the heart of the system. Here is where all of the control of the CPU takes place, and it must take place invisibly to the user, so they need not ever be aware of it's presence. Now you might ask, how does this Kernel thing know when to activate and de-activate a process? Well, that's where you as a programmer or user would step in. Typically TSS {time-sharing systems} allocate a "Quantum" to active processes. A Quantum is nothing more than a chunk of time to be used by a process. In a round-robin type of scheduler each process can be assigned the same Quantum, or the individual processes can be awarded varying Quantums based on a prioritization scheme. For example: A business is running a series of jobs on a Multi-Tasking system and the operator decides to assign a higher priority to the Payroll job for obvious reasons. By doing so, he/she in effect gives the process {Payroll} a larger Quantum. By now you might be thinking, "That's all fine and good, but that's a much more expensive system than my little ST!". This is very true, but with the speed of the MC68000, and some built in features of the ST system, coupled with the sheer speed of instruction handling provided by GFA Basic, you can actually schedule multiple processes to be handled at a single time. So without further ado, let's talk a bit about setting up limited multi-tasking within a running application written in GFA Basic. There are essentially two ways that you might initiate this type of job handling on the ST with GFA Basic. The first, {which will suit most tasks} is to use the Timer command from within a master scheduling procedure {Dispatcher}, or to call on a routine that has been written in C or 68000 Assembler and compiled or assembled to do the job for you using the C or Call commands. The method used in the example compiled program utilizes the first method. While the internal handling of the processes is undoutedly the easiest, it is also the less flexible at least in terms of running multiple programs versus multiple processes. It is doubtful that you would be able to successfully run multiple applications at once without the control of an exterior shell program {kernel}. But then again even the applications mentioned above that Multi-Task do not run several programs at once, {the exception is Beckemeyer's MT C Shell, it actually will run several applications at once from a parent Command Shell and Kernel}. So here in the next section I'll rough up a diagram of what is necessary for an application to include to make Multi-Tasking a reality. Oh by the way, this is a very rough approximation of what must happen. I'll leave the more involved details to your own ingenuity. START | Job I/O and Selection {Perhaps a CLI} | Pre-Process and assign PID {process ID's} | | The Kernel Here we assign the Quantum for Processes and dispatch the running of those processes until they are ended. / | \ Process 1 Process 2 Process 3 | As processes end, new ones may be assigned as desired. | Until no more processes are active | End of Program I told you it was ROUGH! But I think it gets the idea across nicely enough. So at this point you might ask "That's fine and dandy, but why would I ever want to Multi-Task anyway?". If you have ever felt impatient while your Terminal program sits there staring at you with it's great big pale irridescent eye while downloading a HUGE file from a BBS, and you were powerless to do anything but wait till it was finished you will understand the need and applicability of Multi-Tasking. With Multi-Tasking on your side, you could perhaps drop out and play a game while the file is finishing in the background. Or take the instance of the games {Silent Service or Flight Simulator II} mentioned above. They are both very, very involved and maintain several processes at once, thus necessitating a form of Multi-Tasking. Who likes looking at a game screen that just does one thing at a time? Not Me! I want action with things moving all over the place and sound, and, and, well you get the idea. Any one that has used or seen Tim Purves's BBS will also get an appreciation for what can be accomplished with Multi-Tasking. The little demo program I've included in this ARChive will give you a glimpse of a brand of Multi-Tasking that is possible with GFA Basic. The Processes may be independently killed by pressing either the 1,2,or 3 keys on the keyboard, or you may press the right mouse button to stop the currently active process. When you do so, an alert box appears and asks if you would like to kill the process. The number of the active process appears in the upper right hand corner of the screen and also in the alert box. At that time, you may either kill it or allow it to continue. I opted to use the AES and alert boxes so that when chosen all processes would STOP momentarily so that you could in effect see a freeze frame of the activity. I could have used a non destructive process that allowed the activity to continue while waiting for your response, but that was not the intent of the demo. If you have killed a process and desire to start it up again, just press the 1,2,or 3 keys on the keyboard. The numbers relate directly to the processes and windows represented on the screen. When all of the processes are terminated, the program will exit normally to the GEM Desktop. The Question? Why, you might ask yourself, is this guy doing this, and why has he not uploaded the source code to the demo? The answer to that is that I want to see what sort of reaction you all have about this. If there is enough interest in this subject, perhaps and I do mean maybe, I can develop a Kernel that will handle several types of scheduling for you. I'm not totally confident in that theory as of yet, but without any interest in the user and programmer community I will definitely not pursue it any further. I just thought that some {hopefully many} of you would be interested in a product that could be merged into your own programs and would {nearly} painlessly dispatch Multi-Tasking for you. Since I am not sure as to where this demo will end up, the contact points are listed below: On GEnie send Email to address = > GRIFJOHN or MCP.TECH01 and On Compuserve send Email to address = > 75766,505 At this point it is just in the idea stage, but from the above discussion and included demo program, you can see that it is possible even if in a limited fashion. Some of you may even run with the idea yourselves. If you do, I wish you all of the luck in the world, {you're going to need it, heh...heh..}. For all of you doubting Thomas'es out there, it wasn't too long ago that all I heard on GEnie was "Gee... GFA Basic sure would be nice if you could just use Dialog Boxes...", some even said it couldn't be done. That's why I wrote The GFA Basic Companion(tm). So perhaps this program's for you! At any rate, please spend a dime or two and leave me a note on one of the two mentioned billboards, or you can drop me a letter at: Marathon Computer Press P.O. Box 68503 Virginia Beach, VA 23455-9433 Your comments will be appreciated.